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Abstract 


This specification defines a Uniform Resource Name (URN) namespace 
for the Global System for Mobile Communications Association (GSMA) 
and a Namespace Specific String (NSS) for the International Mobile 
station Equipment Identity (IMEI), as well as an associated parameter 
for the International Mobile station Equipment Identity and Software 
Version number (IMEISV). The IMEI and IMEISV were introduced as part 
of the specification for the GSM and are also now incorporated by the 
3rd Generation Partnership Project (3GPP) as part of the 3GPP 
specification for GSM, Universal Mobile Telecommunications System 
(UMTS), and 3GPP Long Term Evolution (LTE) networks. The IMEI and 
IMEISV are used to uniquely identify Mobile Equipment within these 
systems and are managed by the GSMA. URNs from this namespace almost 
always contain personally identifiable information and need to be 
treated accordingly. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7254. 
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Copyright Notice 


Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 
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1. Introduction 


This specification defines a Uniform Resource Name (URN) namespace 
for the Global System for Mobile Communications Association (GSMA) 
and a Namespace Specific String (NSS) for the International Mobile 
station Equipment Identity (IMEI), as well as an associated parameter 
for the International Mobile station Equipment Identity and Software 
Version number (IMEISV) as per the namespace registration requirement 
found in RFC 3406 [1]. The Namespace Identifier (NID) ’gsma’ is for 
identities used in GSM, Universal Mobile Telecommunications System 
(UMTS), and Long Term Evolution (LTE) networks. The IMEI and the 
IMEISV are managed by the GSMA, so this NID is managed by the GSMA. 
While this specification currently defines only the ’imei’ NSS under 
the ’gsma’ NID, additional NSS under the 'gsma’ NID may be specified 
in the future by the GSMA, using the procedure for URN NSS changes 
and additions (currently through the publication of future 
Informational RFCs approved by IETF consensus). 
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The IMEI is 15 decimal digits long and includes a Type Allocation 
Code (TAC) of 8 decimal digits and a Serial Number (SNR) of 6 decimal 
digits plus a Spare decimal digit. The TAC identifies the type of 
the Mobile Equipment and is chosen from a range of values allocated 
to the Mobile Equipment manufacturer in order to uniquely identify 
the model of the Mobile Equipment. The SNR is an individual serial 
number that uniquely identifies each Mobile Equipment device within 
the TAC. The Spare digit is used as a Check digit to validate the 
IMEI and is always set to the value 0 when transmitted by the Mobile 
Equipment. 


The IMEISV is 16 decimal digits long and includes the TAC and SNR, 
same as for the IMEI, but also includes a 2 decimal digit Software 
Version Number (SVN), which is allocated by the Mobile Equipment 
manufacturer to identify the software version of the Mobile 
Equipment. 


The information here is meant to be a concise guide for those wishing 
to use the IMEI and IMEISV as URNs. Nothing in this document should 
be construed to override 3GPP Technical Specification (TS) 23.003 
[2], which specifies the IMEI and IMEISV. 


The GSMA is a global trade association representing nearly 800 mobile 
phone operators across 220 territories and countries of the world. 
The primary goals of the GSMA are to ensure that mobile phones and 
wireless services work globally and are easily accessible. Further 
details about the GSMA’s role in allocating the IMEI and the IMEISV, 
as well as the IMEI and IMEISV allocation guidelines, can be found in 
GSMA Permanent Reference Document (PRD) TS.06 [3]. 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [4]. 

3. Namespace Registration Template 
Namespace ID: ‘’gsma’ 
Registration Information: 


Registration version number: 1 


Registration date: 2014-01-12 
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Declared registrant of the namespace: 


Registering organization: 


Name: GSM Association 


Address: 1st Floor, Mid City Place, 


71 High Holborn, London, England 


Designated contact person: 


Name: Paul Gosden 


Coordinates: pgosden@gsma.com 


Declaration of syntactic structure: 


The identifier is expressed in American Standard Code for 
Information Interchange (ASCII) characters and has a hierarchical 
structure expressed using the Augmented Backus-Naur Form (ABNF) 
defined in RFC 5234 [5], as follows: 


gsma-urn 
gsma-NID 
gsma-NSS = 
imei-specifier = 


"urn:" gsma-NID ":" gsma-NSS 

" gsma " 

imei-specifier / future-gsma-specifier 
"imei:" ( imeival / ext-imei ) 


[ ";" sw-version-param ] 
[ ";" imei-version-param ] 


ext-imei = gsma-defined-nonempty ;GSMA defined and 


sw-version-param = 


imei-version-param = 
software-version 
imei-version-val 
future-gsma-specifier = 


future-specifier 


future-param 

par-name 

par-value 

EQUAL 
gsma-defined-nonempty 
gsma-urn-char 


; IETF consensus 
; required 
"svn=" software-version 
"vers="imei-version-val 
= 2DIGIT 
= DIGIT 
future-specifier 
*( ";" future-param ) 


gsma-—defined-nonempty ;GSMA defined 


= par-name [ EQUAL par-value ] 


gsma-—defined-nonempty 
gsma-—defined-nonempty 

wow 

1*gsma-urn-char 

ALPHA / DIGIT 

/ wow / wow / wow / wow / "n 
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An NSS for the IMEI is defined under the ’gsma’ NID. 


An IMEI is an identifier under the ’gsma’ NID that uniquely 
identifies the mobile devices used in the GSM, UMTS, and LTE 
networks. 


The representation of the IMEI is defined in 3GPP TS 23.003 [2]. 
To accurately represent an IMEI received in a cellular signaling 
message (see 3GPP TS 24.008 [6]) as a URN, it is necessary to 
convert the received binary (Binary Coded Decimal (BCD)) encoded 
bit sequence to a decimal digit string representation. Each field 
has its representation for humans as a decimal digit string with 
the most significant digit first. 


The following ABNF includes the set of core rules in RFC 5234 [5]; 
the core rules are not repeated here. 


A URN with the ’imei’ NSS contains one ’imeival’, and its formal 
definition is provided by the following ABNF (RFC 5234) [5]: 


" 


imeival = tac "-" snr "-" spare 
tac = 8DIGIT 
snr = 6DIGIT 
spare = DIGIT 


<future-gsma-specifier> and <gsma-defined-nonempty> can comprise 
any ASCII characters compliant with the above ABNF. 


The GSMA will take responsibility for the ’gsma’ namespace, 
including the ’imei’ NSS. 


Additional NSS may be added for future identifiers needed by the 
GSMA, at their discretion. Only URNs with the ’imei’ NSS are 
considered to be "GSMA IMEI URNs", and use in IETF protocols of 
other NSS that might be defined in the future will require IETF 
consensus. 


Relevant ancillary documentation: 


See IMEI Allocation and Approval Guidelines (GSMA PRD TS.06) [3] 
and 3GPP TS 23.003 [2]. 
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Identifier uniqueness considerations: 


Identifiers under the ’gsma’ NID are defined and assigned by the 
GSMA after ensuring that the URNs to be assigned are unique. 
Uniqueness is achieved by checking against the IANA registry of 
previously assigned names. 


Procedures are in place to ensure that each IMEI is uniquely 
assigned by the Mobile Equipment manufacturer so that it is 
guaranteed to uniquely identify that particular Mobile Equipment 
device. 


Procedures are in place to ensure that each IMEISV is uniquely 
assigned by the Mobile Equipment manufacturer so that it is 
guaranteed to uniquely identify that particular Mobile Equipment 
device and the specific software version installed. 


Identifier persistence considerations: 


The GSMA is committed to maintaining uniqueness and persistence of 
all resources identified by assigned URNs. 


As the NID sought is ’gsma’ and "GSMA" is the long-standing 
acronym for the trade association that represents the mobile phone 
operators, the URN should also persist indefinitely (at least as 
long as there is a need for its use). The assignment process 
guarantees that names are not reassigned. The binding between the 
name and its resource is permanent. 


The TAC and SNR portions of the IMEI and IMEISV are permanently 
stored in the Mobile Equipment, so they remain persistent as long 
as the Mobile Equipment exists. The process for TAC and SNR 
assignment is documented in GSMA PRD TS.06 [3], and once assigned, 
the TAC and SNR values are not reassigned to other Mobile 
Equipment devices. The SVN portion of the IMEISV may be modified 
by software when new versions are installed but should be 
persistent for the duration of the installation of that specific 
version of software. 


Process of identifier assignment: 
The GSMA will manage the <NSS> (including ’imei’) and 
<future-gsma-specifier> identifier resources to maintain 


uniqueness. 


The process for IMEI and IMEISV assignment is documented in GSMA 
PRD TS.06 [3]. 
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Process for identifier resolution: 


Since the ’gsma’ NSS is not currently globally resolvable, this is 
not applicable. 


Rules for Lexical Equivalence: 


Two GSMA IMEI URNs are equivalent if they have the same ’imeival’ 
value, and the same parameter values in the same sequential order, 
with the exception that the ’/vers=0’ parameter is to be ignored 
for the purposes of comparison. All of these comparisons are to 
be case insensitive. 


Any identifier in the ’gsma’ NSS can be compared using the normal 
mechanisms for percent-encoded UTF-8 strings (see RFC 3629 [7]). 


Conformance with URN Syntax: 


The string representation of the ’gsma’ NID and of the ’imei’ NSS 
is fully compatible with the URN syntax (see RFC 2141 [8]). 


Validation mechanism: 


The IMEI can be validated using the mechanism defined in Annex B 
of 3GPP TS 23.003 [2]. There is no mechanism defined to validate 
the SVN field of the IMEISV. 


Scope: The GSMA URN is global in scope. 
4. Specification 
4.1. IMEI Parameters 


The optional ’vers’ parameter and the ’ext-imei’ field in the ABNF 
are included for extensibility of the ’imei’ NSS -- for example, if 
the IMEI format is extended in the future (such as with additional 
digits or using hex digits). In this case, the ’vers’ parameter 
would contain a non-zero value and the ’ext-imei’ would be further 
defined to represent the syntax of the extended IMEI format. A value 
of the ‘vers’ parameter equal to 0 or the absence of the ’vers’ 
parameter means the URN format is compliant with the format specified 
here. 


Any change to the format of the ’imei’ NSS requires the use of the 
procedure for URN NSS changes and additions (currently through the 
publication of future Informational RFCs approved by IETF consensus). 
The use of the ’vers’ parameter was chosen for extensibility instead 
of defining a new NSS (e.g., ’imei2’) because it is likely that many 
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applications will only need to perform string compares of the 
‘imeival’. So, even if the format or length of the ’imeival’ changes 
in the future, such applications should continue to work without 
having to be updated to understand a new NSS. 


RFC 7255 [10] specifies how the GSMA IMEI URN can be used as an 
instance ID as specified in RFC 5626 [11]. Any future value of the 
‘vers’ parameter other than 0, or the definition of additional 
parameters that are intended to be used as part of an instance ID, 
will require an update to RFC 7255 [10]. 


For example: 

urn:gsma: imei: 90420156-025763-0; vers=0 
The IMEISV is an identifier that uniquely identifies mobile devices 
and their associated software versions used in the GSM, UMTS, and LTE 


networks. The representation of the IMEISV is defined in 3GPP TS 
23.003 [2]. 


To represent the IMEISV, the URN parameter ’svn’ is appended to the 
GSMA IMEI URN and set equal to the decimal string representation of 
the two software version number (svn) digits in the IMEISV, and the 
Spare digit in the IMEI ’imeival’ is set to zero. 
For example: 
urn:gsma: imei: 90420156-025763-0; svn=42 

4.2. IMEI Format 

4.2.1. Type Allocation Code (TAC) 
The TAC is an 8 decimal digit value. The TAC identifies the type of 
the Mobile Equipment and is chosen from a range of values allocated 


to the Mobile Equipment manufacturer in order to uniquely identify 
the model of the Mobile Equipment. 


4.2.2. Serial Number (SNR) 


The SNR is a 6 decimal digit value. The SNR is an individual serial 
number that uniquely identifies each Mobile Equipment device within 
the TAC. 
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-2.3. Spare 


The Spare is a single decimal digit. When the IMEI is stored on the 
Mobile Equipment and network equipment, it contains a value that is 
used as a Check digit and is intended to avoid manual reporting 
errors (e.g., when customers register stolen mobiles at the 
operator’s customer care desk) and also to help guard against the 
possibility of incorrect entries being provisioned in the network 
equipment. The Spare is always set to zero when transmitted by the 
Mobile Equipment (including when in the IMEI URN format). Annex B of 
3GPP TS 23.003 [2] specifies a mechanism for computing the actual 
Check digit in order to validate the TAC and SNR. 


-2.4. Binary Encoding 


When included in a cellular signaling message, the IMEI format is 15 
decimal digits encoded in 8 octets, using BCD as defined in 3GPP TS 
24.008 [6]. Figure 1 is an abstract representation of a BCD-encoded 
IMEI stored in memory (the actual storage format in memory is 
implementation specific). In Figure 1, the most significant digit of 
the TAC is coded in the least significant bits of octet 1. The most 
significant digit of the SNR is coded in the least significant bits 
of octet 5. The Spare digit is coded in the least significant bits 
of octet 8. When included in an identity element in a cellular 
signaling message, the most significant digit of the TAC is 

included in digit 1 of the identity element in Figure 10.5.4 of 

3GPP TS 24.008 [6]. 


14 13 12 1110 9 8 7 6 5 4 3 2 1 0 Decimal Digits 
+—-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 


| | | s| 
| T | S | pl 
| A | N | al 
C R r 
e 
+--+4+-----+-----+-----4--+4--4-----4-----+4+--4+--+ 
1 2 3 4 5 6 7 8 Octets 


Figure 1: IMEI Format 
.3. IMEISV Format 
.3.1. Type Allocation Code (TAC) 


The TAC is the same as the TAC in the IMEI (see Section 4.2.1). 
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4.3.2. Serial Number (SNR) 
The SNR is the same as the SNR in the IMEI (see Section 4.2.2). 
4.3.3. Software Version Number (SVN) 


The Software Version Number is allocated by the mobile device 
manufacturer to identify the software version of the mobile device. 


4.3.4. Binary Encoding 


When included in a cellular signaling message, the IMEISV format is 
16 decimal digits encoded in 8 octets using BCD as defined in 3GPP TS 


24.008 [6]. Figure 2 is an abstract representation of a BCD-encoded 
IMEISV stored in memory (the actual storage format in memory is 
implementation specific). In Figure 2, the most significant digit of 


the TAC is coded in the most significant bits of octet 1. The most 
Significant digit of the SNR is coded in the most significant bits of 
octet 5. The most significant digit of the SVN is coded in the most 
Significant bits of octet 8. When included in an identity element in 
a cellular signaling message, the most significant digit of the TAC 
is included in digit 1 of the identity element in Figure 10.5.4 of 
3GPP TS 24.008 [6]. 


15 1413121110 9 8 7 6 5 4 3 2 1 = 0. Decimal Digits 
+—--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 


T S S 
A N V 
a ee be! 
+----- +----- +----- +----- +----- +----- +----- +----- + 
1 2 3 4 5 6 af 8 Octets 
Figure 2: IMEISV Format 
5. Community Considerations 


GSM, UMTS, and LTE mobile devices will be interoperating with 
Internet devices for a variety of voice and data services. To do 
this, they need to make use of Internet protocols that will operate 
end to end between devices in GSM/UMTS/LTE networks and those in the 
general Internet. Some of these protocols require the use of URNs as 
identifiers. Within the GSM/UMTS/LTE networks, mobile devices are 
identified by their IMEI or IMEISV. Internet users will need to be 
able to receive and include the GSMA URN in various Internet protocol 
elements to facilitate communication between pure Internet-based 
devices and GSM/UMTS/LTE mobile devices. Thus, the existence and 
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syntax of these namespaces need to be available to the general 
Internet community, and the namespace needs to be reserved with IANA 
in order to guarantee uniqueness and prevent potential namespace 
conflicts both within the Internet and within GSM/UMTS/LTE networks. 
Conversely, Internet implementations will not generally possess IMEI 
identifiers. The identifiers generated by such implementations will 
typically be URNs within namespaces other than ’gsma’ and may, 
depending on context, even be non-URN URIs. Implementations are 
advised to be ready to process URIs other than ’gsma’ namespaced 
URNs, so as to aid in interoperability. 


6. Namespace Considerations 


A URN was considered the most appropriate URI to represent the IMEI 
and IMEISV, as these identifiers may be used and transported 
similarly to the Universally Unique Identifier (UUID), which is 
defined as a URN in RFC 4122 [12]. Since specifications for 
protocols that are used to transport device identifiers often require 
the device identifier to be globally unique and in the URN format, it 
is necessary that the URN formats are defined to represent the IMEI 
and IMEISV. 


7. (IANA Considerations 


In accordance with BCP 66 (RFC 3406) [1], IANA has registered the 
Formal URN Namespace ’gsma’ in the "Uniform Resource Names (URN) 
Namespaces" registry, using the registration template presented in 
Section 3 of this document. 


8. Security and Privacy Considerations 


IMEIs (but with the Spare value set to the value of the Check digit) 
are displayable on most mobile devices and in many cases are printed 
on the case within the battery compartment. Anyone with brief 
physical access to the mobile device can therefore easily obtain the 
IMEI. Therefore, IMEIs MUST NOT be used as security capabilities 
(identifiers whose mere possession grants access). Unfortunately, 
there are currently examples of some applications that are using the 
IMEI for authorization. Also, some service provider’s customer 
service departments have been known to use knowledge of the IMEI as 
"proof" that the caller is the legitimate owner of the mobile device. 
Both of these are inappropriate uses of the IMEI. 


While the specific software version of the mobile device only 
identifies the lower-layer software that has undergone and passed 
certification testing, and not the operating system or application 
software, the software version could identify software that is 
vulnerable to attacks or is known to contain security holes. 
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Therefore, the IMEISV MUST only be delivered to trusted entities 
within carrier networks and not provided to the Internet at large, as 
it could help a malicious device identify that the mobile device is 
running software that is known to be vulnerable to certain attacks. 
This concern is similar to concerns regarding the use of the 
User-Agent header in the Session Initiation Protocol (SIP) as 
specified in RFC 3261 [13]. Therefore, the IMEISV (that is, the IMEI 
URN with a ’svn’ parameter) MUST NOT be delivered to devices that are 
not trusted. IMEIs are almost always personally identifiable 
information, and so these URNs MUST be treated as personally 
identifiable information in all cases. In order to prevent violating 
a user’s privacy, the IMEI URN MUST NOT be included in messages 
intended to convey any level of anonymity. 


Since the IMEI is permanently assigned to the mobile device and is 
not modified when the ownership of the mobile device changes (even 
upon a complete software reload of the device), the IMEI URN MUST NOT 
be used as a user identifier or user address by an application. 

Using the IMEI to identify a user or as a user address could result 
in communications destined for a previous owner of a device being 
received by the new device owner or could allow the new device owner 
to access information or services owned by the previous device owner. 


Additionally, since the IMEI identifies the mobile device, it 
potentially could be used to identify and track users for the 
purposes of surveillance and call data mining if sent in the clear. 


Since the IMEI is personally identifiable information, uses of the 
IMEI URN with IETF protocols require a specification and IETF Expert 
Review [14] in order to ensure that privacy concerns are 
appropriately addressed. Protocols carrying the IMEI URN SHOULD at a 
minimum use channels that are strongly hop-by-hop encrypted, and it 
is RECOMMENDED that end-to-end encryption be used. 


Additional security considerations are specified in 3GPP TS 22.016 
[9]. Specifically, the IMEI is to be incorporated in a module that 
is contained within the terminal. The IMEI SHALL NOT be changed 
after the terminal’s production process. It SHALL resist tampering, 
i.e., manipulation and change, by any means (e.g., physical, 
electrical, and software). 
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